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Abstract 


This document defines Media Gateway Control Protocol (MGCP) packages 
that enable a Call Agent to authorize and monitor the transition of a 
connection to and from Voiceband Data (VBD) with or without 
redundancy and FEC (forward error correction). Although the focus is 
on VBD, the General-Purpose Media Descriptor Parameter package can be 
used to authorize other modes of operation, not relevant to VBD, for 
a particular codec. In addition to defining these new packages, this 
document describes the use of the Media Format Parameter package and 
Fax package with VBD, redundancy, and FEC. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6498. 
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1. Applicability Statement 


This document defines a mechanism that requires media stream 
integrity protection. The document specifies different alternative 
mechanisms but does not choose one of them as mandatory-to-implement. 
Consequently, the use of this specification is only suitable in 
environments that specify and use at least one of these alternative 
mechanisms. Please see the Security Considerations section for 
further details. 


2. Introduction 


The term Voiceband Data (or simply VBD) refers to the use of a 
suitable voiceband codec (commonly G.71lu or G.71lla) for the 
transport of data payloads using RTP as defined in RFC 3550 
[RFC3550]. This document defines Media Gateway Control Protocol 
(MGCP) [RFC3435] packages that enable a Call Agent to authorize and 
monitor the transition of a connection to and from VBD with or 
without redundancy [RFC2198] and FEC (forward error correction) 
[RFC5109]. 
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There are a number of different VBD procedures. These procedures 
vary in terms of how the transition to and from VBD is coordinated 
end to end. Some coordination techniques are mutually negotiated by 
the two gateways using the Session Description Protocol (SDP) 
[RFC4566]. These coordination techniques include 


o ITU-T Recommendation V.150.1 State Signaling Event (SSE) [V1501] 
o ITU-T Recommendation V.152 Payload Type Switching [V152] 


Other coordination techniques are not negotiated. For example, the 
detection of fax, modem, and text tones in the direction from the IP 
to the General Switched Telephone Network (GSTN) may result in a 
switch to VBD or a change (e.g., disable echo cancellation) to the 
gateway controlled VBD procedure already in place. The IP-side 
detected tone serves as both a VBD stimulus and a coordination 
technique. 


RFC 4733 [RFC4733] and RFC 4734 [RFC4734] can be used to convey fax 
and modem events and tones. As with IP-side tone detection, the 
telephone event may serve as both a VBD stimulus and a coordination 
technique. Note that while the use of RFC 4733 and RFC 4734 to 
convey fax and modem events and tones is negotiated, the use of 

RFC 4733 and RFC 4734 as a gateway VBD coordination technique (at 
present) is not. 


The Voiceband Data (VBD) package is defined to support all VBD 
procedures. This document does not address the relative merits of 
different procedures nor does it advocate one procedure over another. 


We will use the term VBD to refer to Voiceband Data in general. In 
referring to VBD in the context of the package, we will use the term 
VBD package. We use the term "audio" (with double quotes) to refer 
to the IANA media type. We use the term audio (without double 
quotes) to refer to the use of the "audio" media type for (most 
commonly) voice. 


A package is defined for the General-Purpose Media Descriptor 
Parameter [V152]. In the context of VBD, the General-Purpose Media 
Descriptor Parameter (GPMD) package is used to authorize the 
negotiation of a particular codec for use with VBD. The General- 
Purpose Media Descriptor Parameter is "general" in nature and may be 
used in applications other than VBD. 


The Media Format Parameter (FM) package [RFC3660] describes the use 
of the standard audio MIME subtype "RED" in conjunction with the 
"fmtp" LocalConnectionOption in order to authorize the negotiation of 
redundancy [RFC2198], to identify the levels of redundancy and the 
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media format associated with each redundancy level. This document 
will further explore the use of the FM package with VBD and 
redundancy. 


The VBD package is intended to complement the MGCP Fax (FXR) package 
[RFC5347]. This document will explore the use of the FXR package 
with VBD. 


The VBD package definition is provided in Section 4. The GPMD 
package definition is provided in Section 5. In Section 6, we 
discuss the use of the FM package with VBD and redundancy. In 
Section 7, we discuss the use of the FM package with VBD and FEC. In 
Section 8, we discuss the use of the FXR package with VBD. In 
Section 9, we provide two call flow examples showing how to use the 


VBD and GPMD packages. Security considerations are found in 
Section 10, followed by the IANA considerations (Section 11) and 
references. 

3. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


4. Voiceband Data Package Definition 


This package is defined for Voiceband Data (VBD). The package 
defines new events as detailed below. 


Package Name: VBD 
Package Version: 0 
4.1. Events and Signals 


The following events are defined in support of the above: 


| Symbol | Definition | R | s | Duration | 
| gwvbd | Gateway Controlled VBD x | 
| nopvbd | No Negotiated Procedure for VBD | x | | 


This is standard MGCP package format as defined in Section 6.6 of 
RFC 3435 [RFC3435]. The definitions of the individual events are 
provided in the following subsections. 
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4.1.1. Gateway Controlled Voiceband Data 


The gwvbd procedure can be used by the gateway to control and decide 
how to handle VBD calls without Call Agent involvement. The "Gateway 
Controlled Voiceband Data" (or simply "gwvbd") event occurs when a 
gwvbd procedure has been negotiated and VBD stimulus is detected. 

The "gwvbd" event may occur when the gwvbd procedure is updated 
(e.g., upon detecting new stimulus) and when the procedure fails. 

The "gwvbd" event occurs when the gwvbd procedure ends. The gwvbd 
procedure MUST be negotiated with the other side by passing and 
recognizing relevant parameters via the LocalConnectionDescriptor and 
RemoteConnectionDescriptor. 


The following recommendations from MGCP [RFC3435] apply. 


In this section, we provide a formal description of the protocol 
syntax, using ABNF as defined in "Augmented BNF for Syntax 
Specifications: ABNF" [RFC5234]. The syntax makes use of the core 
rules defined in Appendix B.1 of [RFC5234], which are not included 
here. Furthermore, the syntax follows the case-sensitivity rules of 
[RFC5234], i.e., MGCP is case-insensitive (but SDP is not). It 
should be noted that ABNF does not provide for implicit specification 
of linear white space, and MGCP messages MUST thus follow the 
explicit linear white space rules provided in the grammar below. 
However, in line with general robustness principles, implementers are 
strongly encouraged to tolerate additional linear white space in 
messages received. 


The RequestedEvent parameter is encoded as 
GwVvbdRegEvent = "gwvbd" 
The ObservedEvent parameter is encoded as 


GwVbdObsEvent = GwVbdObsEventStart / GwVbdObsEventUpdate / 
GwVbdObsEventStop / GwVbdObsEventFailure 


GwVbdObsEventStart = "gwvbd(start" Rc [Codec] [Coord] [Dir] ")" 
GwVbdObsEventUpdate = "gwvbd(update" Rc [Codec] [Dir] ")" 
GwVbdObsEventStop = "gwvbd(stop" [Rc] [Codec] ")" 
GwVbdObsEventFailure = "gwvbd(failure" [Rc] [Codec] ")" 
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Codec = "," *WSP "codec=" CodecString 
CodecString = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-" / "_" / 
"m.y / m7") 
Coord = "," *WSP "coord=" CoordinationTechnique 
CoordinationTechnique = "v1l52ptsw" / "v150fw" 
Re = "," *WSP "rc=" ReasonCode 
ReasonCode = 1* (ALPHA / DIGIT / "-" /"" /"™" / ™/™) 
; Refer to the values listed in the tables below. 
Dir = "," *WSP "dir=" Direction 
Direction = "GstnToIp" / "IpToGstn" 
ABNF does not provide for position-independent parameters. The "rec", 


"codec", "coord", and "dir" parameters, if present, MUST appear in 
the relative order shown. 


The "start", "update", "stop", and "failure" ObservedEvent parameters 
are defined as follows: 


1) VBD Start (start) 


The gwvbd procedure was initiated. The Call Agent SHOULD refrain 
from issuing media handling instructions to the gateway until 
either a "gwvbd(stop)" or "gwvbd(failure)" event is generated. 
One and only one "gwvbd(stop)" or "gwvbd(failure)" event is 
generated corresponding to each "gwvbd(start)" event. 


2) VBD Update (update) 


The gwvbd procedure was updated. The "gwvbd(update)" event MUST 
only be generated after a "gwvbd(start)" event and before a 
"gwvbd(stop)" or "“gwvbd(failure)" event. 


3) VBD Stop (stop) 


The gwvbd procedure ended, and the gateway did not detect any 
errors. Note that this does not necessarily imply a successful 
fax, modem, or text transmission. It merely indicates that the 
gwvbd procedure has ended and the procedure itself did not 
encounter any errors. The "stop" parameter may correspond to a 
change from VBD to a non-VBD "audio" codec or from VBD to another 
media type such as "image" or "text". This change may be under 
Call Agent or gateway control. For example, the gateway may 
coordinate the switch from VBD to "image/t38" through the exchange 
of SSEs [T38] [V152]. For an example involving Call Agent 
control, refer to the "MC" Reason Code. In both examples, the 
gwvbd procedure ends with the media change. 
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4) VBD Failure (failure) 


The gwvbd procedure ended abnormally. Some kind of problem was 
encountered in the gwvbd procedure, and the procedure ended. 


When the "gwvbd" event is reported, exactly one of the "Start", 
"update", "stop", or "failure" parameters MUST be present and MUST be 
the first parameter supplied. 


The "re", "codec", "coord", and "dir" ObservedEvent parameters are 
defined as follows: 


1) Reason Code (rc=<ReasonCode>) 


With the "start" and "update" parameters, the reason for 
triggering the switch/change to VBD. With the "stop" and 
"failure" parameters, the reason for triggering the switch from 
VBD. The Reason Codes in the following table, which are based on 
the ITU-T Fax/Textphone/Modem Tones Detection package [H2482], 
ITU-T V.150.1 Amendment 1 [V1501A1], and ITU-T V.152 [V152], may 
be used with the "start" and "update" parameters: 
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| ReasonCode | Description 

| CNG | T.30 fax calling 

| v21iflag | V.21 tone and flags for fax answering | 

| CIV18 | v.8 CI with V.18 call function 

| XCI | V.18 XCI | 

| v18txp | v.18 txp | 

| Belltone | Bell 103 carrier, high- or low-frequency channel | 

(ITU-T Recommendation V.18) 

| Baudot | Baudot initial tone and character (ITU-T | 

| | Recommendation V.18) | 

| Edt | EDT initial tone and character (ITU-T 

| | Recommendation V.18) | 

| CIdata | V.8 CI with any data call function | 
CT | V.25 calling tone 

| CIfax V.8 CI with fax call function 

| V2itone | V.21 carrier, high- or low-frequency channel | 

| V23tone | v.23 carrier, high- or low-frequency channel | 

| V8bis | V.8 bis modem handshaking signal 

| ANS | V.25 ANS, equivalent to T.30 CED from answering | 

| | terminal | 
/ANS V.25 ANS with periodic phase reversals 

| ANSam | v.8 ANSam | 

| /ANSam | V.8 ANSam with periodic phase reversals | 

| CMFax | V.8 CM sequence indicating fax call function | 

| JMFax | V.8 JM sequence indicating fax call function | 
CMData V.8 CM sequence indicating unspecified data 

| | call function | 

| JMData | V.8 JM sequence indicating unspecified data | 

| | call function | 

| CMText | V.8 CM sequence indicating text call function | 

| JMText | V.8 JM sequence indicating text call function | 

| PTSW | Payload type switch as defined in V.152 


For solutions involving textphones using a modulation with 
interspersed text and speech on the same "channel", such as Baudot 
and EDT, the Call Agent SHOULD interpret the ReasonCode parameter 
as part of the "vbd/gwvbd(start)" event in order to differentiate 
between fax, modem, and text. In the case of interspersed text 
and speech, the Call Agent SHOULD remove the notification request 
for "vbd/gwvbd" upon receiving the "vbd/gwvbd(start)" event in 
order to avoid large numbers of notifications. 


For example, 


vbd/gwvbd (start, rc=Baudot) 
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With a ReasonCode of "PTSW", the Call Agent cannot differentiate 
text from fax/modem. In this case, the Call Agent SHOULD adopt a 
policy that guards against large numbers of notifications. We 
consider several such policies. 


The Call Agent MAY remove the notification request for "vbd/gwvbd" 
upon receiving the "vbd/gwvbd(start, rc=PTSW)" event. With this 
policy, "update", "stop", and "failure" notifications will not be 
generated with text AND fax/modem. 


The Call Agent MAY wait for a subsequent "vbd/gwvbd(update)" event 
that differentiates text from fax/modem. If the ReasonCode 
indicates interspersed text and speech, the Call Agent SHOULD 
remove the notification request for "vbd/gwvbd". For example, 


vbd/gwvbd (update, rc=Edt) 


The Call Agent MAY remove the notification request for "vbd/gwvbd" 
upon receiving a "vbd/gwvbd(stop)" event without having 
differentiated between text and fax/modem. 


The Call Agent MAY remove the notification request for "vbd/gwvbd" 
after having received a number of "vbd/gwvbd(start)" events 
without having differentiated between text and fax/modem. The 
specific number of events after which the notification request is 
removed is considered an implementation detail outside the scope 
of this specification. 


Reason Codes applicable with the "stop" parameter are listed 
below: 


SIL Bidirectional silence 
| Voice | Voice signals 
| PTSW | Payload type switch as defined in V.152 | 
| MC | Media change 


The "MC" Reason Code indicates that the media type has changed 
from "audio" (to "image", "text", ...) or the "audio" media format 
has changed from a VBD codec (for a reason other than "PTSW"). 

For example, the gwvbd procedure may be initiated upon detecting 
called terminal identification (CED). Subsequently, the Call 
Agent controlled T.38 procedure of the MGCP Fax (FXR) package 
[RFC5347] may be initiated upon detecting V.21 flags. Upon 
receipt of a "t38(start)" event, the Call Agent will instruct the 
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gateway to switch from VBD to T.38 through the use of a 
ModifyConnection command involving a LocalConnectionOption 
encoding method of "L:a:image/t38" and/or a 
RemoteConnectionDescriptor with an "image/t38" media description. 


This stops the gwvbd procedure. There is no specific 
interdependency between the VBD package and the FXR package (or 
any other package). The gwvbd procedure is stopped as a 


consequence of the media change, not as a direct consequence of 
the T.38 procedure being initiated. Note that in this situation 
the "t38(start)" event will be sent before the "gwvbd(stop)" 
event. The Call Agent MAY choose to infer that the gwvbd 
procedure has ended upon receiving the "t38(start)" event and 
disable the notification of the "gwvbd" event. Refer to the 
example call flow in Section 9.2. 


Reason Codes applicable with the "failure" parameter: 


The list of Reason Codes may be extended to include values with 
meaning mutually understood between the gateway and the Call 
Agent. Obviously, the use of extended values MUST be a 
provisionable option on the gateway in order to ensure 
interoperability with the Call Agent. 


Codec String (codec=<CodecString>) 


With the "start" and "update" parameters, the codec parameter 
describes the MIME type associated with the switch/change to VBD 
(e.g., "“audio/RED", "audio/PCMU", "audio/PCMA", "audio/G726-32", 
"audio/clearmode", ...). With the "stop" and "failure" 
parameters, the codec parameter describes the MIME type associated 
with the switch from VBD (e.g., "audio/G729", "image/t38", "text/ 
t140", "audio/v150mr", ...). These strings should be full MIME 
types as listed in http://www.iana.org/assignments/media-types. 
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3) Coordination Technique (coord=<CoordinationTechnique>) 


The technique used to coordinate the transition to and from VBD 
with the remote endpoint. The coordination techniques are 
summarized in the following table: 


vl52ptsw V.152 Payload Type Switching 
| vl50£w | V.150.1 SSE 


With the "v152ptsw" coordination technique, payload type switching 
[V152] is used to coordinate the transition to and from VBD. 


With the "v150fw" coordination technique, state signaling events 
[V1501] are used to coordinate the transition to and from VBD. 


The list of coordination techniques may be extended to include 
values with meaning mutually understood between the gateway and 
the Call Agent. Obviously, the use of extended values MUST be a 
provisionable option on the gateway in order to ensure 
interoperability with the Call Agent. 


4) Direction of Stimulus (dir=<Direction>) 
With the "start" and "update" parameters, the "dir" parameter 


describes the direction of the stimulus that resulted in the 
switch/change to VBD. 


GstnToIp 


| 

| Stimulus detected in the direction 

| from the GSTN to IP network, 

| including fax, modem, and text tones. 
IpToGstn | Stimulus detected in the direction 

| from the IP to GSTN network, 

| including fax, modem, and text tones 

(e.g., IP-side tone detection); 
| RTP packet with VBD payload type 
| (e.g., V.152 or V.150.1). 
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Call Agents and gateways MUST implement the "start" and "stop" 
parameters and MAY implement the "update" and "failure" parameters. 
Call Agents and gateways MAY implement the "coord", "codec", and 
"dir" parameters. Call Agents MAY, and gateways MUST, implement the 
"re" parameter in conjunction with the "start" and "update" 
parameters. Call Agents and gateways MAY implement the "rc" 
parameter in conjunction with the "stop" and "failure" parameters. A 
Call Agent MUST ignore all unknown ObservedEvent parameters, 
including parameters that are defined as part of this specification 
and not implemented. 


4.1.1.1. Gateway Controlled Voiceband Data Examples 


The following examples illustrate the encoding of the "gwvbd(start)" 
event: 


O: vbd/gwvbd(start, rc=ANS) 
O: vbd/gwvbd (start, rc=ANS, codec=audio/PCMU, coord=v152ptsw) 
O: vbd/gwvbd (start, rc=PTSW, codec=audio/RED) 


The following example illustrates the encoding of the "gwvbd (update)" 
event: 


O: vbd/gwvbd (update, rc=/ANSam, dir=IpToGstn) 


The following examples illustrate the encoding of the "gwvbd(stop)" 
event: 


O: vbd/gwvbd (stop) 
O: vbd/gwvbd (stop, rc=SIL, codec=audio/G729) 
O: vbd/gwvbd (stop, rc=MC, codec=image/t38) 


The following examples illustrate the encoding of the 
"gwvbd (failure)" event: 


O: vbd/gwvbd (failure, codec=audio/G729) 
O: vbd/gwvbd (failure, rc=TO, codec=audio/G729) 


4.1.2. No Negotiated Procedure for Voiceband Data 


The "No Negotiated Procedure for Voiceband Data" (or simply "nopvbd") 
event occurs when a VBD procedure has not been negotiated and VBD 
stimulus is detected. The "nopvbd" event may occur when the 
procedure is updated (e.g., upon detecting new stimulus), when the 
procedure ends, and when the procedure fails. Even though a 
procedure was not negotiated, a VBD handling procedure MAY still be 
in place locally on the endpoint, as described further below. 
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The nopvbd procedure MAY involve VBD handling including, but not 
limited to, adjusting gain and jitter, disabling voice activity 
detection, and DC offset filters. The nopvbd procedure MAY involve 
switching to another codec. The Call Agent MAY have to issue further 
commands in response to the "nopvbd" event in order to ensure a 
successful VBD call. 


As with the "gwvbd" event, the same recommendations from MGCP 
[RFC3435] regarding ABNF, general robustness principles, and white 
space apply. 


The RequestedEvent parameter is encoded as 


NopVbdReqEvent = "nopvbd" 


The ObservedEvent parameter is encoded as 


NopVbdObsEvent = NopVbdObsEventStart / NopVbdObsEventUpdate / 
NopVbdObsEventStop / NopVbdObsEventFailure 


NopVbdObsEventStart = "nopvbd(start" Re [Codec] [Dir] ")" 
NopVbdObsEventUpdate = "nopvbd(update" Rc [Codec] [Dir] ")" 
NopVbdObsEvent Stop = "nopvbd(stop" [Rc] [Codec] ")" 

( 


NopVbdObsEventFailure 


"nopvbd(failure" [Rc] [Codec] ")" 


The following ABNF notation is common with the "gwvbd" ObservedEvent 


parameter: 

Codec = "," *WSP "codec=" CodecString 

CodecString = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-" / "_" / 

we / m7") 
Re = "," *WSP "rc=" ReasonCode 
ReasonCode = 1* (ALPHA / DIGIT / wow / Mom 7 wow / m7") 
; Refer to the values listed in the tables above. 

Dir = "," *WSP "dir=" Direction 

Direction = "GstnToIp" / "IpToGstn" 
ABNF does not provide for position-independent parameters. The "rc", 


"codec", and "dir" parameters, if present, MUST appear in the 
relative order shown. 
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The "start", "update", "stop", and "failure" ObservedEvent parameters 
are defined as follows: 


1) VBD Start (start) 


The nopvbd procedure was initiated. The Call Agent may have to 
issue further commands in order to ensure a successful VBD call 
(e.g., switch to another codec). At most one "nopvbd(stop)" or 
"nopvbd(failure)" event MAY be generated corresponding to each 
"nopvbd(start)" event. The Call Agent MAY need to infer that the 
nopvbd procedure has ended. 


2) VBD Update (update) 


The nopvbd procedure was updated. The "nopvbd(update)" event MUST 
only be generated after a "nopvbd(start)" event and before a 
"nopvbd(stop)" or "nopvbd(failure)" event. 


3) VBD Stop (stop) 


The nopvbd procedure ended, and the gateway did not detect any 
errors. Note that this does not necessarily imply a successful 
fax, modem, or text transmission. It merely indicates that the 
nopvbd procedure has ended and the procedure itself did not 
encounter any errors. Refer to the definition of the "stop" 
parameter from the "gwvbd" event in Section 4.1.1 for additional 
information. 


4) VBD Failure (failure) 


The nopvbd procedure ended abnormally. Some kind of problem was 
encountered in the nopvbd procedure, and the procedure ended. 


Call Agents and gateways MUST implement the "start" parameter and MAY 


implement the "update", "stop", and "failure" parameters. Call 
Agents MAY, and gateways MUST, implement the "rc" parameter in 
conjunction with the "start" and "update" parameters. Call Agents 


and gateways MAY implement the "rc" parameter in conjunction with the 
"stop" and "failure" parameters. A Call Agent MUST ignore all 
unknown ObservedEvent parameters including parameters that are 
defined as part of this specification and not implemented. 


The definitions of the "re", "codec", and "dir" ObservedEvent 
parameters are taken from the "gwvbd" event. 


As with the "gwvbd" event, the same recommendations regarding 
interspersed text and speech apply. 
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4.1.2.1. No Negotiated Procedure for Voiceband Data Examples 


The following examples illustrate the encoding of the "nopvbd(start)" 
event: 


O: vbd/nopvbd (start, rc=ANS) 
O: vbd/nopvbd(start, rc=ANS, codec=audio/PCMU) 


The following example illustrates the encoding of the 
"nopvbd (update) " event: 


O: vbd/nopvbd (update, rc=/ANSam, dir=IpToGstn) 


The following examples illustrate the encoding of the "nopvbd(stop)" 
event: 


O: vbd/nopvbd (stop) 
O: vbd/nopvbd (stop, re=SIL, codec=audio/G729) 
O: vbd/nopvbd (stop, rc=MC, codec=image/t38) 


The following examples illustrate the encoding of the 
"nopvbd(failure)" event: 


O: vbd/nopvbd (failure, codec=audio/G729) 
O: vbd/nopvbd(failure, rc=TO, codec=audio/G729) 


5. General-Purpose Media Descriptor Parameter Package Definition 
This package is defined for the General-Purpose Media Descriptor 


Parameter [V152]. The package defines a new LocalConnectionOption as 
detailed below. 


Package Name: GPMD 
Package Version: 0 
5.1. LocalConnectionOptions 


The following new LocalConnectionOptions field is defined in support 
of the above: 


The definition of the LocalConnectionOption is provided in the 
following subsection. 
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5.1.1. General-Purpose Media Descriptor Parameter 


The General-Purpose Media Descriptor Parameter LocalConnectionOption 
is similar to the "gpmd" SDP [RFC4566] attribute defined in ITU-T 
Recommendation V.152 [V152] and is applicable to all of the same 
media formats that the corresponding SDP "gpmd" attribute could be 
used with. 


The General-Purpose Media Descriptor Parameter is encoded as the 
keyword "gpmd" or "o-gpmd", followed by a colon and a quoted string 
beginning with the media format name (MIME subtype only) followed by 
a space, followed by the media format parameters associated with that 
media format: 


gpmd/gpmd:"<format> <parameter list>" 


For simplicity, we will use the terms "codec" and "media format" 
interchangeably in the following. Multiple media formats may be 
indicated by either repeating the "gpmd" LocalConnectionOption 
multiple times, such as 


L: a:codecl;codec2, gpmd/gpmd:"codecl parameterX", 
gpmd/gpmd:"codec2 parameteryY" 


or alternatively by having a single "gpmd" keyword followed by a 
colon, and a semicolon-separated list of quoted strings for each 


General-Purpose Media Descriptor Parameter, as in 


L: a:codecl;codec2, gpmd/gpmd:"codecl parameterXx"; 
"codec2 parameterYy" 


The two formats may be mixed: 
L: a:codecl;codec2;codec3, gpmd/gpmd:"codecl parameterX", 
gpmd/gpmd:"codec2 parameterY"; 
"codec3 parameterZ" 
The carriage returns above are included for formatting reasons only 
and are not permissible in a real implementation. This holds true 


for all of the examples in this document. 


If it is possible for the same codec to be requested with and without 
the "gpmd" parameter, the following could result: 


L: a:codecl;codecl, gpmd/gpmd:"codecl parameterX" 
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However, it would not be clear whether the "gpmd" parameter was to be 
applied to the first or the second occurrence of the codec. The 
problem is that codec ordering is important (i.e., codecs are listed 
in preferred order), and the above syntax does not provide a way to 
indicate whether "parameterX" is preferred (i.e., associated with the 
first "codecl") or not (i.e., associated with the second "codecl1"). 
In order to resolve this dilemma, the codec in the "gpmd" media 
format is followed by a colon and an <order>, where <order> is a 
number from one to N for occurrences of the same codec in the codec 
list. For example, 


L:a:codecl;codecl, gpmd/gpmd:"codec1l:2 parameterX" 


indicates that "parameterX" is associated with the second instance of 
"codec1" in the "a:codecl;codecl" list. If an invalid instance 
number is supplied (e.g., instance 3 where there are only two 
instances), then error code 524 -- inconsistency in local connection 
options -- will be returned. In the absence of an <order>, the first 
instance is assumed. 


Prepending "gpmd" with the string "o-" (i.e., "“o-gpmd") indicates 
that the parameter is optional. In that case, the gateway may decide 
not to use the "gpmd" parameter specified, or only use it in part. 


If the "gpmd" LocalConnectionOption parameter is not optional (i.e., 
does not have "o-" in front of it), and the LocalConnectionOption 
parameter value is either not recognized or not supported, then the 
associated codec is considered "not supported". 


When auditing capabilities, the "gpmd" LocalConnectionOption 
parameter MUST be returned with a semicolon-separated list of 
supported formats and/or multiple independent "gpmd" parameters, 


as in 


A: a:codecl;codec2, gpmd/gpmd:"codecl parameterX"; 
"codec2 parameterYy" 


or 


A: a:codecl;codecl, gpmd/gpmd:"codecl parameterxX" 
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One example uses the General-Purpose Media Descriptor Parameter 
LocalConnectionOption in conjunction with gateway controlled 
Voiceband Data (or simply VBD) using payload type switching [V152]. 
In the context of VBD, the <format> must be an RTP/AVP payload type. 
The <parameter list> is a semicolon-separated list of 
"parameter=value" pairs: 


L: a:codecl, gpmd/gpmd:"codecl parameterX=ValueA; parameterY=ValueB" 


In the example below, G.729 is an audio codec and G.71lu is a VBD 
codec: 


L: a:G729;PCMU, gpmd/gpmd:"PCMU vbd=yes" 


The corresponding media description in the SDP as part of the 
connection request acknowledgment might look like 


m=audio 12345 RTP/AVP 18 96 
a=rtpmap:96 PCMU/8000 
a=gpmd:96 vbd=yes 


If a request is made to audit the capabilities of an endpoint, and 
the endpoint supports G.71lu as both an audio and VBD codec, then the 
"gpmd" LocalConnectionOption parameter might look like 


A: a:PCMU, p:10-40, e:on, s:on, 
m:sendonly; recvonly; sendrecv; inactive 

A: a:PCMU, p:10-40, e:on, s:off, 
m:sendonly; recvonly; sendrecv; inactive, 


gpmd/gpmd:"PCMU vbd=yes" 


Given that some parameters, e.g., silence suppression, are only 
compatible with G.71llu as an audio codec, then the gateway MUST 
return different capability sets corresponding to audio and VBD. 


If we combine V.152 and redundancy [RFC2198], an example 
LocalConnectionOption might look like the example below. In this 
example, G.729 is an audio codec and G.711lu is a VBD codec with a 
redundancy level of one: 


L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU" 
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The corresponding media description in the SDP as part of the 
connection request acknowledgment might look like 


m=audio 12345 RTP/AVP 18 96 97 
a=rtpmap:96 RED/8000 

a=fmtp:96 97/97 

a=rtpmap:97 PCMU/8000 
a=gpmd:97 vbd=yes 


Refer to Section 6 for more examples involving V.152 and redundancy. 
6. Use of Media Format Parameter Package with VBD and Redundancy 


The MGCP Media Format Parameter (FM) package [RFC3660] in conjunction 
with the standard audio MIME subtype "RED" may be used by the Call 
Agent to authorize the negotiation of redundancy [RFC2198], to 
identify the levels of redundancy and the media format associated 
with each redundancy level. An example of this was demonstrated in 
Section 5. 


The FM package states that the "fmtp" LocalConnectionOption MUST be 
returned when auditing capabilities. Applying this to VBD and 
redundancy might result in 


A: a:PCMU, p:10-40, e:on, s:on, 
m:sendonly; recvonly; sendrecv; inactive 
A: a:RED;PCMU, p:10-40, e:on, s:off, 


m:sendonly; recvonly; sendrecv; inactive, 
gpemd/gpmd:"PCMU vbd=yes", 
fmtp: "RED PCMU/PCMU" 


The FM package defines "instance syntax", in which 
L:a:codecl;codecl, fmtp:"codec1:2 formatX" 
indicates that "formatX" is associated with the second instance of 
"codecl" in the "a:codecl;codec1" list. The examples in the FM 
package are limited to the use of the instance syntax in conjunction 
with the media format. We propose the use of the instance syntax in 


conjunction with the media format parameters 


L:a:codecl; codec2;codec3;codec2, fmtp:"codec3 codec2:2/codec2:2" 
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Let’s build on the example of Section 5. In the example below, G.729 
is an audio codec, and G.71llu is both an audio codec and a VBD codec 
with a redundancy level of one: 


L: a:G729;PCMU;RED;PCMU, gpmd/gpmd:"PCMU:2 vbd=yes", 
fmtp: "RED PCMU:2/PCMU:2" 


The corresponding media description in the SDP as part of the 
connection request acknowledgment might look like 


m=audio 12345 RTP/AVP 18 0 96 97 
a=rtpmap:96 RED/8000 

a=fmtp:96 97/97 

a=rtpmap:97 PCMU/8000 

a=gpmd:97 vbd=yes 


Note that the relative preference of the LocalConnectionOption 
encoding methods is preserved in the "audio" media formats (i.e., 
payload types) as part of the media description. In this example, 
this reflects a preference for V.152 with redundancy versus without. 
No preference is inferred from the relative order of the different 
LocalConnectionOptions, namely "a", "gpmd/gpmd", and "fmtp". 


A Call Agent can authorize the negotiation of audio codecs and VBD 
codecs involving different levels of redundancy. In the example 
below, G.71lu is a VBD codec with a redundancy level of two 
(preferred) or one: 


L: a:G729;RED;RED;PCMU, fmtp:"RED PCMU/PCMU/PCMU", 
fmtp:"RED:2 PCMU/PCMU", 
gpmd/gpmd:"PCMU vbd=yes" 


The corresponding media description in the SDP as part of the 
connection request acknowledgment might look like 


m=audio 12345 RTP/AVP 18 96 97 98 
a=rtpmap:96 RED/8000 

a=fmtp:96 98/98/98 

a=rtpmap:97 RED/8000 

a=fmtp:97 98/98 

a=rtpmap:98 PCMU/8000 

a=gpmd:98 vbd=yes 
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Redundancy can be applied to both audio codecs and VBD codecs. In 
the example below, G.729 is an audio codec with a redundancy level of 
two and G.71lu is a VBD codec with a redundancy level of one: 


L: a:RED;G729;RED;PCMU, fmtp:"RED G729/G729/G729", 
fmtp:"RED:2 PCMU/PCMU", 
gpmd/gpmd:"PCMU vbd=yes" 


The corresponding media description in the SDP as part of the 
connection request acknowledgment might look like 


m=audio 12345 RTP/AVP 96 18 97 98 
a=rtpmap:96 RED/8000 

a=fmtp:96 18/18/18 

a=rtpmap:97 RED/8000 

a=fmtp:97 98/98 

a=rtpmap:98 PCMU/8000 

a=gpmd:98 vbd=yes 


7. Use of Media Format Parameter Package with VBD and FEC 
A Call Agent may authorize the negotiation of forward error 
correction (FEC) [RFC5109] with the standard audio MIME subtype 


"parityfec": 


L: a:PCMU;parityfec 


By default, we assume that FEC packets are to be sent as a separate 
stream. The corresponding media description in the SDP as part of 
the connection request acknowledgment might look like 


v=0 

c=IN IP4 192.0.2.0 

m=audio 49170 RTP/AVP 0 96 
a=rtpmap:96 parityfec/8000 
a=fmtp:96 49172 IN IP4 192.0.2.0 


If FEC is to be sent as a secondary codec in the redundant codec 
payload format [RFC2198], we again leverage the MGCP Media Format 
Parameter (FM) package [RFC3660] in conjunction with the standard 
audio MIME subtype "RED": 


L: a:G729;RED;PCMU;parityfec, gpmd/gpmd:"PCMU vbd=yes", 
fmtp:"RED PCMU/parityfec" 
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8. 


The corresponding media description might look like 


v=0 

c=IN IP4 192.0.2.0 

m=audio 49170 RTP/AVP 18 96 97 98 
a=rtpmap:96 RED/8000 

a=fmtp:96 97/98 

a=rtpmap:97 PCMU/8000 

a=gpmd:97 vbd=yes 

a=rtpmap:98 parityfec/8000 


The FM package states that the "fmtp" LocalConnectionOption MUST be 
returned when auditing capabilities. Applying this to VBD, 
redundancy and FEC might result in 


A: a:PCMU, p:10-40, e:on, s:on, 
m:sendonly; recvonly; sendrecv; inactive 
A: a:RED;PCMU;parityfec, p:10-40, e:on, s:off, 


m:sendonly; recvonly; sendrecv; inactive, 
gpmd/gpmd:"PCMU vbd=yes", 
fmtp: "RED PCMU/parityfec" 


Use of Fax Package with VBD 


The MGCP Fax (FXR) package [RFC5347] is used by a Call Agent to 
authorize fax handling, including Call Agent controlled T.38 and 
gateway procedures such as V.152. With the FXR package, VBD falls 
into one of two categories: "special fax handling" as part of the 
gateway procedure (resulting in the "gwfax" event), or "no special 
fax handling" as part of the gateway and Off procedures (resulting in 
the "nopfax" event). In order for a VBD procedure to fall into the 
"special fax handling" category, support for it MUST be negotiated 
with the other side by passing and recognizing relevant parameters 
via the LocalConnectionDescriptor and RemoteConnectionDescriptor. 


A gateway controlled VBD procedure such as V.152 MUST fall into the 
category of gateway controlled mode involving "special fax handling". 
The resulting "gwfax" event is what informs the Call Agent to refrain 
from issuing media handling instructions that could otherwise have a 
negative impact on the gateway procedure. 
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Consider the following example (with shorthand SDP notation): 


CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 

CEL 

M: sendrecv 

L: a:G729;PCMU, gpmd/gpmd:"PCMU vbd=yes", fxr/fx:t38;gw 
Xé ods 

R: fxr/t38, fxr/gwfax, fxr/nopfax 


v=0 

c=IN IP4 192.0.2.1 

m=audio 3456 RTP/AVP 18 96 
a=rtpmap:96 PCMU/8000 
a=gpmd:96 vbd=yes 


200 2000 OK 
Trai 


v=0 

c=IN IP4 192.0.2.2 

m=audio 1296 RTP/AVP 18 96 
a=rtpmap:96 PCMU/8000 
a=gpmd:96 vbd=yes 


The RemoteConnectionDescriptor does not indicate support for "image/ 
t38" as a latent capability [RFC3407]. Consequently, the gateway 
will not initiate the T.38 strict fax procedure, "t38", upon 
detecting fax stimulus (i.e., CNG, V.21 flags, etc.). However, the 
two endpoints did successfully negotiate a gateway controlled VBD 
procedure (e.g., V.152); therefore, a gateway controlled mode 
involving "special fax handling" is used. The "gwfax(start)" event 
will be generated upon detecting VBD (including fax) stimulus. 


A Call Agent can express a preference for a gateway procedure 
involving "special fax handling" over a T.38 procedure (strict or 
loose). For example, 

L: fxr/fx:gw;t38 
and 

L: fxr/fx:gw;t38-loose 
However, with the existing syntax of the FXR package, a Call Agent 
cannot express a preference for one gateway procedure over another, 


each with possibly different preferences relative to a T.38 
procedure. 


Stone, et al. Informational [Page 24] 


RFC 6498 MGCP VBD Package February 2012 


The FXR package allows a gateway to implement additional fax handling 
parameters. We define just such a parameter by qualifying the 
existing "gw" parameter with a list of one or more MIME types: 


Gateway = "gw[" mimeType ox "|" mimeType) "]" 
mimeType = mimeMediaType "/" mimeSubType 
; mimeMediaType and mimeSubType from 
; http://www.iana.org/assignments/media-types/ 
By qualifying the "gw" parameter with a list of MIME types, we narrow 
the scope of the gateway procedure. Consider the following examples 
in which the Call Agent authorizes the use of a gateway controlled 
fax handling procedure: 
- involving "image/t38" (e.g., T.380UDPTL, T.380TCP): 
L: a:G729, fxr/fx:gw[image/t38] 
- involving VBD (e.g., PCMU and V.152): 
L: a:G729;PCMU, gpmd/gpmd:"PCMU vbd=yes", fxr/fx:gw[audio/PCMU] 


- involving VBD with redundancy (e.g., PCMU, V.152, 
and RFC 2198): 


L: a:G729;RED;PCMU, fmtp:"RED PCMU/PCMU", 
gpmd/gpmd:"PCMU vbd=yes", fxr/fx:gw[audio/RED|audio/PCMU] 


Only "special fax handling" involving one of the specified MIME types 
is authorized. Support for "special fax handling" involving one of 
the specified MIME types MUST be negotiated, or this "instance" of 
the gateway procedure is not initiated. Consider the following 
example in which the Call Agent authorizes the use of a gateway 
controlled fax handling procedure: 


- involving "audio/t38" (e.g., T.380RTP): 
L: a:G729;t38, fxr/fx:gw[audio/t38] 


In this example, the call will fail if the gateway fails to negotiate 
"audio/t38". 


The "fx" LocalConnectionOption MAY now involve multiple instances of 
the "gw" parameter, each with a different list of MIME types. In 
order to authorize "no special fax handling", the Call Agent MUST 
include the "gw" parameter without a MIME type, or the "off" 
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parameter. The instance of the "gw" parameter without a MIME type 
should appear as the last instance of the "gw" parameter. In the 
following example, 
L: a:G729;PCMU, fxr/fx:gw[image/t38]; gw 
the Call Agent authorizes the use of, and expresses a preference for, 
1. Gateway controlled image/t38 (e.g., T.380UDPTL) 
2. Any other gateway procedure with "special fax handling" 
3. No special fax handling (this is a function of the "fxr/fx:gw" 
parameter as defined in Section 2.1 of the MGCP Fax (FXR) package 
[RFC5347]) 


If present, the "off" parameter should appear as the last parameter. 
In the following example, 


L: a:G729;PCMU;t38, fxr/fx:gw[audio/t38];off 
the Call Agent authorizes the use of, and expresses a preference for, 
1. Gateway controlled audio/t38 (e.g., T.380RTP) 
2. No special fax handling 
We can express relative preferences for different gateway controlled 
fax handling procedures, not only with respect to one another, but 


with respect to T.38 procedures. Consider the following preferential 
list of fax handling procedures: 


1. Gateway controlled audio/t38 (e.g., T.380RTP) 
2. Gateway controlled image/t38 (e.g., T.380UDPTL) 
3. Call Agent controlled image/t38 


4. Gateway controlled VBD with redundancy (e.g., PCMU, V.152, and 
RFC 2198) 


5. Gateway controlled VBD without redundancy (e.g., PCMU and V.152) 


6. Any other gateway procedure with "special fax handling" 


7. No special fax handling (this is a function of the "fxr/fx:gw" 
parameter as defined in Section 2.1 of the MGCP Fax (FXR) package 
[RFC5347]) 
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This would be expressed as 


L: a:G/729;PCMU;t38; RED; PCMU, 
gpmd/gpmd:"PCMU:2 vbd=yes", 
fmtp:"RED PCMU:2/PCMU:2", 
fxr/fx:gw[audio/t38 | image/t38] ;t38; gw[audio/RED |audio/PCMU:2];gw 


Note that the bracketed form of the "gw" parameter is NOT defined as 
part of the VBD package. The bracketed form of the "gw" parameter is 
defined as an extension to the FXR package. Gateways that implement 
the bracketed form of the "gw" parameter MUST return this form of the 
parameter when capabilities are audited as illustrated by the 
following example: 


A: fxr/f£x:t38;t38-loose; gw[audio/t38 | image/t38]; gw; off 


Support for the bracketed "gw" parameter MAY be spread across 
multiple capability lines: 


A: a:RED;PCMU, p:10-40, e:on, s:off, 
m:sendonly; recvonly; sendrecv; inactive, 
gpmd/gpmd:"PCMU vbd=yes", 

fmtp: "RED PCMU/PCMU", 
fxr/fx:gw[audio/RED | audio/PCMU] 

A: a:t38, fxr/fx:gw[audio/t38] 

A: a:image/t38, fxr/fx:t38;t38-loose; gw[image/t38] 


A Call Agent SHOULD only attempt to leverage the bracketed form of 
the "gw" parameter in conjunction with an endpoint that indicates 
support for the bracketed syntax as part of its capabilities. 


Call Agents and gateways that do not support this form of the "gw" 
parameter MUST ignore the bracketed MIME type information consistent 
with the MGCP grammar [RFC3435]. 


9. Call Flow Examples 


In this section, we provide two call flow examples. The first one 
illustrates a modem call under gateway control using V.152. The 
second one illustrates a fax call under gateway control using V.152 
and Call Agent controlled T.38. 


9.1. Modem Call with Gateway Controlled VBD 
In this example, both sides support gateway controlled VBD using 
V.152 with redundancy. We assume that the originating and 


terminating Call Agents communicate via the Session Initiation 
Protocol (SIP) [RFC3261]: 
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| #| GW-o | CA-o | CA-t | GW-t 

E A | | | 

| 2| 200 (sdp-o) |-> | | | 

| 3] | INVITE (sdp-o) |-> | | 

| 4| | | CRCX (sdp-o) |-> 

|5] | | <-|200 (sdp-t) | 
6 <- |200 (sdp-t) 

| 3 <- |MDCX (sdp-t) | 

p O 

| 9| | | |<- ANS/T.30 CED| 

|10] | | <- NTFY (gwvbd start) | 

|11] | | 200 |-> 

a start) -> | | 
13 <-|200 

ie ae ee aaee [Aare ane Pepa seas ees | 

|14] | | | (modem ends) | 

|15] | | <- NTFY (gwvbd stop) | 

|16] | | 200 |-> | 

a stop) -> | | 
18 <-|200 

Step 1: 


The Call Agent issues a CreateConnection command to the gateway, 
instructing it to use G.729 media encoding and to notify it of the 
"gwvbd" and "nopvbd" events. The Call Agent authorizes the 
negotiation of G.71lu as a VBD codec with a redundancy level 

of one: 


CRCX 1000 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 

Gee al. 

L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU" 
M: recvonly 
R: vbd/gwvbd, vbd/nopvbd 
X: 1 

Q: process, loop 
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Step 2: 


The gateway acknowledges the 
information as well as V.152 


200 1000 OK 
Ted 


v=0 

o=- 25678 753849 IN IP4 
pem 

c=IN IP4 192.0.2.1 

t=0 0 

m=audio 3456 RTP/AVP 18 
a=rtpmap:96 RED/8000 
a=fmtp:96 97/97 
a=rtpmap:97 PCMU/8000 
a=gpmd:97 vbd=yes 


Step 3: 


command and includes SDP with codec 
and redundancy information: 


192.0.2.1 


96 97 


The originating Call Agent sends a SIP INVITE message with the SDP 
to the terminating Call Agent. 


Step 4: 


The terminating Call Agent issues a CreateConnection command to 
the terminating gateway, instructing it to use G.729 media 
encoding and to notify it of the "gwvbd" and "nopvbd" events. 
Again, the Call Agent authorizes the negotiation of G.71llu as a 
VBD codec with a redundancy level of one: 


RCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 


2 


a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU" 


vbd/gwvbd, vbd/nopvbd 
20 


G 
C 
L 
M: sendrecv 
R 
X 
Q: process, loop 
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v=0 

o=- 25678 753849 IN IP4 192.0.2.1 
ess 

c=IN IP4 192.0.2.1 

t=0 0 


m=audio 3456 RTP/AVP 18 96 97 
a=rtpmap:96 RED/8000 
a=fmtp:96 97/97 

a=rtpmap:97 PCMU/8000 
a=gpmd:97 vbd=yes 


Step 5: 
The terminating gateway supports V.152 and redundancy 


RemoteConnectionDescriptor included indicates that th 
supports V.152 and redundancy. The terminating gatew 


February 2012 


, and the 
e other side 
ay sends back 


a success response with its SDP, which also includes V.152 and 


redundancy information: 


200 2000 OK 
TZ 


v=0 

o=- 25678 753849 IN IP4 192.0.2.2 
ae 

c=IN IP4 192.0.2.2 

t=0 0 

m=audio 1296 RTP/AVP 18 96 97 
a=rtpmap:96 RED/8000 

a=fmtp:96 97/97 

a=rtpmap:97 PCMU/8000 

a=gpmd:97 vbd=yes 


Step 6: 


The terminating Call Agent sends back a SIP 200 OK re 
originating Call Agent, which in turn sends a SIP ACK 
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Step 7: 


The originating Call Agent in turn sends a ModifyConnection 
command to the originating gateway: 


MDCX 1001 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 
Gis al 

Ts Ab 

M: sendrecv 


v=0 

o=- 25678 753849 IN IP4 192.0.2.2 
s=- 

c=IN IP4 192.0.2.2 

t=0 0 


m=audio 1296 RTP/AVP 18 96 97 
a=rtpmap:96 RED/8000 
a=fmtp:96 97/97 

a=rtpmap:97 PCMU/8000 
a=gpmd:97 vbd=yes 


Since the RemoteConnectionDescriptor indicates that the other side 
supports V.152 and redundancy, the gateway will in fact be able to 
use the gateway controlled VBD procedure with redundancy. Had 
there not been any support for V.152 in the 
RemoteConnectionDescriptor, then this command would still have 
succeeded; however, there would be no negotiated procedure for VBD 
handling. 


Step 8: 


The gateway acknowledges the command. At this point, a call is 
established using G.729 encoding, and if a VBD call is detected, 
the gateway controlled VBD procedure will be initiated. 


Steps 9-10: 


Stone, 


A modem call now occurs. The terminating gateway detects a T.30 
CED tone (a.k.a. V.25 ANS) in the GSTN-to-IP direction and begins 
transmitting RTP packets with the negotiated redundant VBD payload 
type (96). 


The "gwvbd(start)" event occurs, and a Notify command is sent to 
the Call Agent: 


NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 


O: vbd/gwvbd(start, rc=ANS, codec=audio/RED, coord=v152ptsw) 
X: 20 
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Step 11: 
The Call Agent acknowledges the Notify command: 
200 2500 OK 
Step 12: 
Upon receiving an RTP packet with the redundant VBD payload type 
(96), the originating gateway begins transmitting RTP packets with 


the redundant VBD payload type. 


The "gwvbd(start)" event occurs, and a Notify command is sent to 
the Call Agent: 


NTFY 1500 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 
O: vbd/gwvbd (start, rc=PTSW, codec=audio/RED) 
Meee AL 
Step 13: 
The Call Agent acknowledges the Notify command: 
200 1500 OK 
Steps 14-15: 
The modem call ends. The terminating gateway detects 
bidirectional silence and begins transmitting RTP packets with the 


negotiated audio payload type (18). 


The "gwvbd(stop)" event occurs, and a Notify command is sent to 
the Call Agent: 


NTFY 2501 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 
O: vbd/gwvbd (stop, rce=SIL, codec=audio/G729) 
X: 20 

Step 16: 


The Call Agent acknowledges the Notify command: 


200 2501 OK 
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Step 17: 
Upon receiving an RTP packet with the audio payload type (18), the 
originating gateway begins transmitting RTP packets with the audio 


payload type. 


The "gwvbd(stop)" event occurs, and a Notify command is sent to 
the Call Agent: 


NTFY 1501 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 
O: vbd/gwvbd (stop, rc=PTSW, codec=audio/G729) 
Xs L 
Step 18: 
The Call Agent acknowledges the Notify command: 
200 1501 OK 


The modem call is now over. 


9.2. Fax Call with Gateway Controlled VBD and Call Agent Controlled 
T38 


In this example, both sides support gateway controlled VBD using 
V.152 with redundancy and Call Agent controlled T.38. We assume that 
the originating and terminating Call Agent communicate via the 
Session Initiation Protocol (SIP) [RFC3261]: 
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| #| GW-o | CA-o | CA-t | GW-t 
| | <- | CRCX | | | 
| 2| 200 (sdp-o) |-> | | | 
|3] | INVITE (sdp-o) |-> | | 
| 4] | | CRCX (sdp-o) |-> 
| 5| | | <-|200 (sdp-t) | 
6 <- |200 (sdp-t) 
| 3 <- |MDCX (sdp-t) | 
| a AE | | | 
| 9| | | |<- ANS/T.30 CED| 
|10] | | <- NTFY (gwvbd start) | 
|11] | | 200|-> 
12|NTFY(gwvbd start) -> 
Fe <-|200 | 
|14] | | <- V.21 Preamble | 
4.53) | | <- NTFY (t38 start) | 
|16| | | 200|-> | 
|17] | | MDCX (t38) |-> 
18 <- |200 (sdp-t2) 
Fel | <- | INVITE (sdp-t2) | 
|20] <- | MDCX (sdp-t2) | | 
|21] 200 (sdp-02) |-> | | | 
|22] | 200 (sdp-02) |-> | | 
|23| | | MDCX (sdp-02) |-> | 
24 <- |200 
ie V.21 Preamble |-> | | 
|26|NTFY (t38 start) |-> | | | 
|27 Se | | | 
ES EE ESE AE E EAEE EEEE | 
|28| | | | (fax ends) | 
29 <- |NTFY (t38 stop) 
Ed | | 200|-> | 
|31|NTFY(t38 stop) |-> | | | 
|32| <- |200 | | | 
Step 1: 


The Call Agent issues a CreateConnection command to the gateway, 
instructing it to use G.729 media encoding and to use either the 
strict T.38 procedure or the gateway procedure. Consequently, the 
Call Agent requests notification of the "t38", "gwfax", "gwvbd", 
and "nopvbd" events. The Call Agent authorizes the negotiation of 
G.71lu as a VBD codec with a redundancy level of one: 
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CRCX 1000 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 
Ce od 
L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU", 
fxr/fx:t38; gw 


M: recvonly 
R: fxr/t38, fxr/gwfax, vbd/gwvbd, vbd/nopvbd 
Xe, 1 
Q: process, loop 
Step 2: 


The gateway acknowledges the command and includes SDP with codec 
information as well as capability, V.152, and redundancy 
information: 


200 1000 OK 
Teil 


v=0 

o=- 25678 753849 IN IP4 192.0.2.1 
s=- 

c=IN IP4 192.0.2.1 

t=0 0 

a=pmft: T38 

m=audio 3456 RTP/AVP 18 96 97 
a=rtpmap:96 RED/8000 

a=fmtp:96 97/97 

a=rtpmap:97 PCMU/8000 

a=gpmd:97 vbd=yes 

a=sqn: 0 

a=cdsc: 1 audio RTP/AVP 18 96 97 
a=cdsc: 4 image udptl t38 


Note that V.152 requires the use of the session-level "a=pmft" SDP 
attribute in order to express a preference for T.38 over V.152 for 
fax handling. 

Step 3: 


The originating Call Agent sends a SIP INVITE message with the SDP 
to the terminating Call Agent. 


Step 4: 
The terminating Call Agent issues a CreateConnection command to 
the terminating gateway, instructing it to use G.729 media 


encoding and to use either the strict T.38 procedure or the 
gateway procedure. Consequently, the Call Agent requests 
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notification of the "t38", "gwfax", "gwvbd", and "nopvbd" events. 
Again, the Call Agent authorizes the negotiation of G.71llu as a 
VBD codec with a redundancy level of one: 


CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 

Cee 2 

L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU", 
fxr/fx:t38; gw 

M: sendrecv 

R: fxr/t38, fxr/gwfax, vbd/gwvbd, vbd/nopvbd 

X: 20 

Q: process, loop 


v=0 

o=- 25678 753849 IN IP4 192.0.2.1 
gs 

c=IN IP4 192.0.2.1 

t=0 0 

a=pmft: T38 

m=audio 3456 RTP/AVP 18 96 97 
a=rtpmap:96 RED/8000 

a=fmtp:96 97/97 

a=rtpmap:97 PCMU/8000 

a=gpmd:97 vbd=yes 

a=sqn: 0 

a=cdsc: 1 audio RTP/AVP 18 96 97 
a=cdsc: 4 image udptl t38 


Step 5: 


The terminating gateway supports T.38, and the 
RemoteConnectionDescriptor included indicates that the other side 
supports T.38 as well, so the strict T.38 Call Agent controlled 
procedure requested can be used. The terminating gateway supports 
V.152 and redundancy, and the RemoteConnectionDescriptor included 
indicates that the other side supports V.152 and redundancy, so 
gateway controlled VBD using V.152 and redundancy can be used for 
modem and text transmissions. The terminating gateway sends back 
a success response with its SDP, which also includes capability, 
V.152, and redundancy information: 


200 2000 OK 
12 


v=0 

o=- 25678 753849 IN IP4 192.0.2.2 
s=- 

c=IN IP4 192.0.2.2 
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t=0 0 

a=pmft: T38 

m=audio 1296 RIP/AVP 18 96 97 
a=rtpmap:96 RED/8000 

a=fmtp:96 97/97 

a=rtpmap:97 PCMU/8000 

a=gpmd:97 vbd=yes 

a=sqn: 0 

a=cdsc: 1 audio RTP/AVP 18 96 97 
a=cdsc: 4 image udptl t38 


Step 6: 


The terminating Call Agent sends back a SIP 200 OK response to the 
originating Call Agent, which in turn sends a SIP ACK (not shown). 


Step 7: 


Stone, 


The originating Call Agent in turn sends a ModifyConnection 
command to the originating gateway: 


MDCX 1001 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 
Cell 

Lesa 

M: sendrecv 


v=0 

o=- 25678 753849 IN IP4 192.0.2.2 
s=- 

c=IN IP4 192.0.2.2 

t=0 0 


a=pmft: T38 

m=audio 1296 RIP/AVP 18 96 97 
a=rtpmap:96 RED/8000 

a=fmtp:96 97/97 

a=rtpmap:97 PCMU/8000 

a=gpmd:97 vbd=yes 

a=sqn: 0 

a=cdsc: 1 audio RTP/AVP 18 96 97 
a=cdsc: 4 image udptl t38 


The ModifyConnection command does not repeat the 
LocalConnectionOptions sent previously. As far as fax handling is 
concerned, the gateway therefore attempts to continue using the 
current fax handling procedure, i.e., strict Call Agent controlled 
T.38. Since the capability information indicates that the other 
side supports T.38, the gateway will in fact be able to use the 
strict Call Agent controlled T.38 procedure. Since the 
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RemoteConnectionDescriptor indicates that the other side supports 
V.152 and redundancy, the gateway will in fact be able to use the 
V.152 VBD procedure with redundancy. 


Step 8: 


The gateway acknowledges the command. At this point, a call is 
established using G.729 encoding, and if a fax call is detected, 
the Call Agent controlled T.38 procedure will be initiated. If a 
modem or text call is detected, the V.152 VBD procedure will be 
initiated. 


Steps 9-10: 


The terminating gateway detects the T.30 CED tone (a.k.a. V.25 
ANS). Since both fax and modem calls can start with this 
sequence, it is not possible to determine that this is a fax call 
until step 14, where the V.21 fax preamble is detected. The 
terminating gateway begins transmitting RTP packets with the 
negotiated redundant VBD payload type (96). 


The "gwvbd(start)" event occurs, and a Notify command is sent to 
the Call Agent: 


NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 
O: vbd/gwvbd (start, rc=ANS, codec=audio/RED, coord=v152ptsw) 
X: 20 
Step 11: 
The Call Agent acknowledges the Notify command: 
200 2500 OK 
Step 12: 
Upon receiving an RTP packet with the redundant VBD payload type 
(96), the originating gateway begins transmitting RTP packets with 


the redundant VBD payload type. 


The "gwvbd(start)" event occurs, and a Notify command is sent to 
the Call Agent: 


NTFY 1500 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 


O: vbd/gwvbd (start, rc=PTSW, codec=audio/RED) 
esis L 
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Step 13: 
The Call Agent acknowledges the Notify command: 
200 1500 OK 
Steps 14-15: 
The terminating gateway detects the V.21 fax preamble. 
The terminating gateway is using the Call Agent controlled T.38 
strict procedure for fax calls, so the "t38(start)" event occurs, 


and a Notify command is sent to the Call Agent: 


NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 
O: fxr/t38 (start) 
X: 20 


Step 16: 
The Call Agent acknowledges the Notify command: 
200 2500 OK 


Step 17: 


The Call Agent then instructs the terminating gateway to change to 
using the "image/t38" MIME type instead: 


MDCX 2002 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 


Ge 2 

hs 22 

L: a:image/t38 
R: fxr/t38 

X: 21 


Note that the Call Agent is no longer requesting notification of 
the "gwvbd" event. 
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Step 18: 


The terminating gateway sends back a success response with its 
SDP, which also includes the "image/t38" media description: 


200 2002 OK 


v=0 

o=- 25678 753850 IN IP4 192.0.2.2 
eae 

c=IN IP4 192.0.2.2 

t=0 0 

m=image 1296 udptl t38 

a=sqn: 0 

a=cdsc: 1 audio RTP/AVP 18 96 97 
a=cpar: a=rtpmap:96 RED/8000 
a=cpar: a=fmtp:96 97/97 

a=cpar: a=rtpmap:97 PCMU/8000 
a=cpar: a=gpmd:97 vbd=yes 
a=cdsc: 4 image udptl t38 


The gwvbd procedure ends due to the media type change. The 
"gwvbd(stop)" event notification would normally be sent at this 
point; however, the Call Agent is no longer requesting 
notification of the "gwvbd" event. The Call Agent would have 
inferred from the "t38(start)" event that the gwvbd procedure 
ended. 


Step 19: 


The terminating Call Agent sends a re-INVITE to the originating 
Call Agent with the updated SDP. 


Step 20: 


The originating Call Agent then sends a ModifyConnection command 
to the originating gateway: 


MDCX 1003 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0 


Ce L 

Tei 

R: fxr/t38 

X: 2 

v=0 

o=- 25678 753850 IN IP4 192.0.2.2 
s=- 


c=IN IP4 192.0.2.2 
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m=image 1296 udptl t38 


a=sqn: 


a=cdsc: 
a=cpar: 
a=cpar: 
a=cpar: 
a=cpar: 
a=cdsc: 


Step 21: 


1 audio RTP/AVP 18 96 97 
a=rtpmap:96 RED/8000 
a=fmtp:96 97/97 
a=rtpmap:97 PCMU/8000 
a=gpmd:97 vbd=yes 

4 image udptl t38 


The originating gateway changes to T.38 and sends back a success 
response with the updated SDP: 


200 1003 OK 


v=0 


o=- 25678 753850 IN IP4 192.0.2.1 


s=- 


c=IN IP4 192.0.2.1 


t=0 0 


m=image 3456 udptl t38 


a=sqn: 


a=cdsc: 
a=cpar: 
a=cpar: 
a=cpar: 
a=cpar: 
a=cdsc: 


1 audio RTP/AVP 18 96 97 
a=rtpmap:96 RED/8000 
a=fmtp:96 97/97 
a=rtpmap:97 PCMU/8000 
a=gpmd:97 vbd=yes 

4 image udptl t38 


Again, the gwvbd procedure ends due to the media type change. The 
"gwvbd (stop)" event notification would normally be sent at this 
point; however, the Call Agent is no longer requesting 
notification of the "gwvbd" event. 


Step 22: 


The originating Call Agent sends a SIP 200 OK response with the 
updated SDP to the terminating Call Agent, which in turn sends a 
SIP ACK (not shown). 
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10. 


Step 23: 


The terminating Call Agent sends a ModifyConnection with the 
updated SDP to the terminating gateway: 


MDCX 2002 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0 
Ciz 
TZ 


v=0 

o=- 25678 753850 IN IP4 192.0.2.1 
eo 

c=IN IP4 192.0.2.1 

t=0 0 

m=image 3456 udptl t38 

a=sqn: 0 

a=cdsc: 1 audio RTP/AVP 18 96 97 
a=cpar: a=rtpmap:96 RED/8000 
a=cpar: a=fmtp:96 97/97 

a=cpar: a=rtpmap:97 PCMU/8000 
a=cpar: a=gpmd:97 vbd=yes 
a=cdsc: 4 image udptl t38 


Steps 24-32: 


These steps correspond to the Call Agent controlled T.38 strict 
procedure as defined in the MGCP Fax (FXR) package [RFC5347]. 


Security Considerations 


This document defines two new packages, both of which have security 
considerations in two areas: 


1. MGCP signaling message security 
2. Media stream security 


From an MGCP signaling security point of view, the MGCP VBD and GPMD 
packages define extensions to the basic MGCP signaling specification 
in accordance with the procedures specified in MGCP [RFC3435], and 
hence the MGCP signaling security considerations and recommendations 
provided in Section 5 of [RFC3435] (namely the use of IPsec) apply 
here as well. Lack of MGCP signaling integrity protection can in 
general be detrimental to any use of MGCP, and the two packages 
defined here do not change that. From a confidentiality point of 
view, the VBD package is not believed to convey any vulnerable or 
privacy-sensitive information. The GPMD package is slightly 
different inasmuch as it does not define any specific parameters that 
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are believed to require confidentiality; however, it is a generic 
parameter that can carry any codec parameter information, and hence 
it is possible that confidential information is conveyed through this 
parameter. If confidentiality of any such potential information is a 
concern, confidentiality protection of the MGCP signaling MUST be 
provided as well. It should be noted that Section 8 of [RFC5406] 
provides considerations for specifying the use of IPsec that are 
above and beyond those provided in [RFC3435]; however, given that the 
use of IPsec for MGCP applies to all of MGCP, and not just the MGCP 
VBD and GPMD packages, we do not specify such additional detail here. 


From a media stream security point of view, the MGCP VBD and GPMD 
packages again define extensions that rely on the general use of 
media streams defined in MGCP [RFC3435], and hence the MGCP media 
stream security considerations and recommendations provided in 
Section 5.1 of [RFC3435] apply here as well. Lack of media stream 
security can in general be detrimental to any media stream 
established via MGCP, and the two packages defined here do not change 
that. Confidentiality concerns apply as for any other media stream. 
Integrity concerns are further compounded by the GPMD package’s use 
of payload type switching, state signaling events, and media stream 
in-band triggers to drive overall Voiceband Data operation: Integrity 
protection with replay protection MUST be used to counter these 
threats. 


Ideally, there would be a single mandatory-to-implement media stream 
security mechanism to provide this integrity protection, and in 
theory there is, since MGCP [RFC3435] defines a media stream security 
mechanism. However, the standard MGCP media stream security 
mechanism defined in [RFC3435] relies on the encryption key ("k=") 
field defined in the original SDP specification [RFC2327], the use of 
which is no longer recommended in the current SDP specification 
[RFC4566]. In practice, this mechanism has also seen very limited 
implementation, and hence there is not much value in relying on it. 
Still, the integrity protection requirement remains, and there are 
several different ways this can be achieved: 


Secure RTP: For RTP-based media streams, the use of Secure RTP 
[RFC3711] with an associated key management mechanism is generally 
preferred at the time of this writing; however, such a mechanism 
has currently not been defined for MGCP. 


PacketCable Security: The PacketCable Network-Based Call Signaling 
Protocol [NCS] defines another media stream security mechanism 
that is generally supported by PacketCable-compliant 
implementations. Implementations targeted for those environments 
SHOULD implement this security mechanism. 
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Lower-Level Security: In the absence of a common media stream 
security mechanism supported by both endpoints, a lower-level 
security mechanism, e.g., IPsec, MUST be used. Note that since 
there is no inherent MGCP signaling support for such a lower-level 
security mechanism, it MUST be configured by other means. 


11. IANA Considerations 


The IANA has registered the following MGCP packages: 


Package Title Name Version 
Voiceband Data VBD 0 
General-Purpose Media Descriptor Parameter GPMD 0 
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